This hasn't actually been submitted for review, but 2 design notes on the current contents that, if changed, I could see getting upstreamed:

1. I think it would be a closer/more honest data model to reorganize the TestScope enum into two enum fields of a struct instead. One would indicate the ecosystem being worked with (Firefox or Servo), and another would indicate whether the Public or Private directories in the chosen ecosystem. These can be combined into a reformed struct TestScope as separate fields:

   enum Browser {
       Firefox,
       Servo,
   }
   
   enum TestVisibility {
       Public,
       Private,
   }
   
   struct TestScope {
       visibility: TestVisibility,
       browser: Browser,
   }

   With all this, we could probably rename TestPath::from_fx_metadata_test to TestPath::from_metadata_test, and require a Browser to be specified as an argument.

2. After the last point, I'd like to see servo: bool become a usage of the proposed enum Browser.¹ Then, the variant can be passed to the proposed/renamed TestPath::from_metadata_test constructor from CLI.

@sagudev: RE: the disabled property not accepting anything but true: Does #143 help?

@sagudev: RE: the disabled property not accepting anything but true: Does #143 help?

Looks like it should (although we rewrite all disabled with true values), but I didn't tried it yet.